Let’s say you’ve got an idea for a groundbreaking health application. Creating a health app that will really make a difference, save lives, or turn the world into a better place is not quite a walk in the park, but also not an insurmountable obstacle if you have a wise plan from the beginning.
So where to start? Pause for a moment and take a look at the rules first. It might come as a surprise, but did you know that software can also be considered as a medical device?
Medical device can also be a software which is intended by its manufacturer to be used specifically to diagnose, prevent, monitor, treat or alleviate disease, injury, or disability in humans[1]. Why do you need to know this? When you are building a healthtech application, a medical device is something to strive towards, but also to know to avoid until the time is right, as it may require you to meet additional conditions.
Exploring local regulations
Norway has the same rights and obligations as other EU Member States with regard to requirements for medical devices through the EEA Agreement.
The Norwegian Medicines Agency (NoMa) is the responsible authority for medical devices in Norway. This implies that the Agency has administrative and advisory responsibilities related to legislation and supervisory authority over manufacturers, distributors and notified bodies. As a part of the market surveillance, all Norwegian manufacturers/ authorized representatives of medical devices need to register in the Medical Device Database (Utstyrsregisteret).
Medical devices need to comply with the essential requirements listed in the regulations and directives before the device can be CE marked - a confirmation that all the regulatory requirements are met. The path towards obtaining CE mark depends on the risk classification of the device[2].
If you have been able to chew through local regulations, then you are ready for GDPR regulations in EU/ UK or HIPAA compliance for the US. The General Data Protection Regulation (GDPR) is considered to be the toughest privacy and security law in the world. Though it was drafted and passed by the European Union (EU), it imposes obligations on organizations anywhere, so long as they target or collect data related to people in the EU[3].
Let’s say you want to be medical device compliant and GDPR-compliant. Then, for example, you must be able to demonstrate obtaining the user's consent to that version of the application. Now, if the user does not agree with the new version of the application, then they must still have the possibility to access and request to download and delete the information the application stores about them. While doing so, the user can not be forced to accept the new version in order to obtain their data. So, just showing a pop-up informing them about the new terms and conditions won’t be enough, the user must actively give their consent by opting in rather than opting in being the default.
For the US, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law that requires the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge[4].
Unlike GDPR, HIPAA is easier to follow and is considered to be quite straightforward. For example, in obtaining a user's consent to process their data, the consent must be given, not assumed, and the user has to be able to see how soon the consent expires.
If this seems like a lot, then you are right - it is a lot for a single person or a company to handle.
But luckily you don’t have to be alone on this journey – there are lots of templates readily available (for example on terms and conditions), and many health-focused accelerators offer legal support to start-ups making it easier to jump through these hoops.
Making a plan
We recommend carefully thinking through every step of your product development journey. For example, if your solution doesn’t store or process patient data, then it might not be subject to medical device requirements, thus making your life easier. As you grow and already have a certain market traction, the solution can be expanded to incorporate those aspects, therefore also expanding its overall functionality.
Otherwise, dealing with all those regulations and requirements and conducting clinical trials might take the steam off the engine that could have otherwise been used to power the growth of the company. After all, building a successful company is a marathon, not a sprint, right?
On one hand, it’s good to gather market feedback even before the pen touches the paper, but we all know that people in the healthtech field, especially doctors and nurses, are constantly overloaded with their work. That’s why we often recommend that start-ups would involve an industry specialist into their team either as a co-founder or advisor to validate their ideas more easily.
Starting the product development
It is often hard to understand where the product development journey could begin from, which features to target, what would add the most value, what is easiest to do - all valid questions. In many health-focused solutions, keeping a diary or a record of activities of some sort is typically an important feature, and in fact the solution doesn’t have to store a lot of information to do so.
The application can, for example, store this information on the user’s phone, without it ever being processed or transferred elsewhere, thus making it easier to manage from the regulatory perspective as patient data is not handled by a third party, only the user themselves. Another example of a low-effort but high reward feature is creating a checklist of standard questions for the patient to answer. The data can again be stored locally and only shown to the doctor from the patient's phone making the tracking of the treatment easier.
Lastly, it is important to note that based on our experience, the initial solutions don’t have to look pretty but they must be functional and actually add value for either the patient or the medical care professional. Working closely with people in the industry is essential to get things right from the start. For example, in the case of a headache, the doctor would also need to know the area of the headache, not just the fact that the head hurts, a fact that is hard to recall days later in the appointment without a proper record.
Building an app or a web-based solution?
People often mistakenly think that there is a big difference, but in most cases, it really doesn’t matter if the solution is hosted on a mobile-friendly website or an app from the users perspective. Where it matters is what the solution must be able to do. For example, if it is known that at some point, there should be a hardware component in the solution, then it might be required that an app is built, as hardware can’t connect to a web-based solution. Only a mobile app or if one wishes to take advantage of not processing patient data by storing it only locally on the users device.
At the end of the day, there are pluses and minuses on both approaches and having a discussion with a knowledgeable partner helps to make the right choice considering the life cycle of the product that is about to be built.
In conclusion
Play by the rules but act wisely. In the health tech domain, start-ups cannot be indifferent to the rules and do what they want, no matter what. If you loose your trustworthiness, it cannot be restored.
[1] Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02017R0745-20200424
[2] Norwegian Medicines Agency https://legemiddelverket.no/english/medical-devices/about-medical-devices
[3] https://gdpr.eu/what-is-gdpr/ Here is the full regulation: https://gdpr.eu/tag/gdpr/
[4] https://www.cdc.gov/phlp/publications/topic/hipaa.html
If you’re building a healthtech app, feel free to get in touch with us by sending an email to karl@thorgate.eu
Read More
